1. Field of the Invention
This invention relates to the field of computer software, and, more specifically, to object-oriented computer applications.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. Sun, Sun Microsystems, the Sun logo, Solaris, xe2x80x9cWrite Once, Run Anywherexe2x80x9d, Java, JavaOS, JavaStation, HotJava Views and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.
2. Background Art
The Java(trademark) programming language, developed by Sun Microsystems(trademark), Inc., has an advantage over other programming languages of being a xe2x80x9cwrite once, run anywherexe2x80x9d(trademark) language. The Java(trademark) programming language provides a substantially platform-independent mechanism for applications to be designed, distributed and executed in the form of bytecode class files. The Java(trademark) virtual machine within the Java(trademark) runtime environment handles the resolution of the bytecodes into the requisite platform dependent instruction set, so that all computing platforms which contain a Java(trademark) runtime environment are capable of executing the same bytecode class files.
Java(trademark)-based systems, such as HotJava View(trademark), are being developed that allow enterprises to load applications, in the form of applets, from a centralized server. Each client on the network accesses and executes the same applications, regardless of computing platform, and the source files remain in a centralized and controlled location. As a result, application management requirements are minimized. This client-server arrangement also permits the use of network computers, i.e., xe2x80x9cthin clientxe2x80x9d computers with minimized I/O and storage facilities.
However, the application memory available to the Java(trademark) runtime environment is limited, particularly in systems which do not implement virtual memory. As a result, the number of applets that can be simultaneously supported in the runtime environment is also limited. Applets may need to be unloaded from the runtime environment to make room in memory for the newly selected applet. The unloading of applets presents a problem for applets which need to run continuously to provide feedback to a user about a change of state in the applet. For example, an electronic mail applet may wish to notify a user when new mail arrives, or a calendar applet may wish to notify a user of an impending appointment. Once applet classes are unloaded from the runtime environment, there is no mechanism by which the unloaded applet may provide feedback to the user. This problem can be better understood from a review of object-oriented programming and the Java(trademark) development and runtime environment.
Object-Oriented Programming
Object-oriented programming is a method of creating computer programs by combining certain fundamental building blocks, and creating relationships among and between the building blocks. The building blocks in object-oriented programming systems are called xe2x80x9cobjects.xe2x80x9d An object is a programming unit that groups together a data structure (one or more instance variables) and the operations (methods) that can use or affect that data. Thus, an object consists of data and one or more operations or procedures that can be performed on that data. The joining of data and operations into a unitary building block is called xe2x80x9cencapsulation.xe2x80x9d
An object can be instructed to perform one of its methods when it receives a xe2x80x9cmessage.xe2x80x9d A message is a command or instruction sent to the object to execute a certain method. A message consists of a method selection (e.g., method name) and a plurality of arguments. A message tells the receiving object what operations to perform.
One advantage of object-oriented programming is the way in which methods are invoked. When a message is sent to an object, it is not necessary for the message to instruct the object how to perform a certain method. It is only necessary to request that the object execute the method. This greatly simplifies program development.
Object-oriented programming languages are predominantly based on a xe2x80x9cclassxe2x80x9d scheme. The class-based object-oriented programming scheme is generally described in Lieberman, xe2x80x9cUsing Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems,xe2x80x9d OOPSLA 86 Proceedings, September 1986, pp. 214-223.
A class defines a type of object that typically includes both variables and methods for the class. An object class is used to create a particular instance of an object. An instance of an object class includes the variables and methods defined for the class. Multiple instances of the same class can be created from an object class. Each instance that is created from the object class is said to be of the same type or class.
To illustrate, an employee object class can include xe2x80x9cnamexe2x80x9d and xe2x80x9csalaryxe2x80x9d instance variables and a xe2x80x9cset_salaryxe2x80x9d method. Instances of the employee object class can be created, or instantiated for each employee in an organization. Each object instance is said to be of type xe2x80x9cemployee.xe2x80x9d Each employee object instance includes xe2x80x9cnamexe2x80x9d and xe2x80x9csalaryxe2x80x9d instance variables and the xe2x80x9cset_salaryxe2x80x9d method. The values associated with the xe2x80x9cnamexe2x80x9d and xe2x80x9csalaryxe2x80x9d variables in each employee object instance contain the name and salary of an employee in the organization. A message can be sent to an employee""s employee object instance to invoke the xe2x80x9cset_salaryxe2x80x9d method to modify the employee""s salary (i.e., the value associated with the xe2x80x9csalaryxe2x80x9d variable in the employee""s employee object).
A hierarchy of classes can be defined such that an object class definition has one or more subclasses. A subclass inherits its parent""s (and grandparent""s etc.) definition. Each subclass in the hierarchy may add to or modify the behavior specified by its parent class. Some object-oriented programming languages support multiple inheritance where a subclass may inherit a class definition from more than one parent class. Other programming languages support only single inheritance, where a subclass is limited to inheriting the class definition of only one parent class. The Java(trademark) programming language also provides a mechanism known as an xe2x80x9cinterfacexe2x80x9d which comprises a set of constant and abstract method declarations. An object class can implement the abstract methods defined in an interface. Both single and multiple inheritance are available to an interface. That is, an interface can inherit an interface definition from more than one parent interface.
An object is a generic term that is used in the object-oriented programming environment to refer to a module that contains related code and variables. A software application can be written using an object-oriented programming language whereby the program""s functionality is implemented using objects.
Java(trademark) Programming and Execution
The Java(trademark) programming language is an object-oriented programming language with each program comprising one or more object classes and interfaces. Unlike many programming languages, in which a program is compiled into machine-dependent, executable program code, Java(trademark) classes are compiled into machine independent bytecode class files. Each class contains code and data in a platform-independent format called the class file format. The computer system acting as the execution vehicle supports the Java(trademark) runtime environment. The runtime environment contains a program called a virtual machine, which is responsible for executing the code in Java(trademark) classes.
Applications may be designed as standalone Java(trademark) applications, or as Java(trademark) xe2x80x9cappletsxe2x80x9d which are identified by an applet tag in an HTML (hypertext markup language) document, and loaded by a browser application. The class files associated with an application or applet may be stored on the local computing system, or on a server accessible over a network. Each class is loaded into the runtime environment, as needed, by the xe2x80x9cclass loader.xe2x80x9d
The classes of an applet are loaded on demand from the network (stored on a server), or from a local file system, when first referenced during the applet""s execution. The runtime environment locates and loads each class file, parses the class file format, allocates memory for the class""s various components, and links the class with other already loaded classes. This process makes the code in the class readily executable by the virtual machine.
FIG. 2 illustrates the compile and runtime environments for a Java(trademark) system. In the compile environment, a software developer creates source files 200, which contain the programmer readable class definitions, including data structures, method implementations and references to other classes. Source files 200 are provided to compiler 201, which compiles source files 200 into compiled xe2x80x9c.classxe2x80x9d files 202 that contain bytecodes executable in a Java(trademark) runtime environment. Bytecode class files 202 are stored (e.g., in temporary or permanent storage) on a server, and are available for download over a network. Alternatively, bytecode class files 202 may be stored locally in a directory on the client platform.
The Java(trademark) runtime environment contains a virtual machine 205 which is able to execute bytecode class files and execute native operating system (xe2x80x9cO/Sxe2x80x9d) calls to operating system 209 when necessary during execution. Virtual machine 205 provides a level of abstraction between the machine independence of the bytecode classes and the machine-dependent instruction set of the underlying computer hardware 210. Class loader and bytecode verifier (xe2x80x9cclass loaderxe2x80x9d) 203 is responsible for loading bytecode class files 202 and supporting Java(trademark) class libraries 204 into virtual machine 205 as needed. Either an interpreter 206 executes the bytecodes directly, or a xe2x80x9cjust-in-timexe2x80x9d (JIT) compiler 207 transforms the bytecodes into machine code, so that they can be executed by the processor in hardware 210. Class loader 203 also verifies the bytecodes of each class file to maintain proper execution and enforcement of Java(trademark) security rules.
Java(trademark) class files are often identified in applet tags within an HTML (hypertext markup language) document. To provide a client with access to class files from a server on a network, a web server application is executed on the server to respond to HTTP (hypertext transport protocol) requests containing URLs (universal resource locators) to HTML documents, also referred to as xe2x80x9cweb pages.xe2x80x9d When a browser application executing on a client platform receives an HTML document (e.g., as a result of requesting an HTML document by forwarding a URL to the web server), the browser application parses the HTML and automatically initiates the download of the bytecode class files 202 when it encounters the applet tag in the HTML document.
Memory is allocated to store and execute the downloaded applet. The allocation of memory to new applets may lead to a low memory condition as the number of applets in the Java(trademark) runtime environment grows. To resolve the low memory condition, older, invisible applets (i.e., applets that are not currently visible on a display) may be unloaded, or xe2x80x9cdestroyedxe2x80x9d (i.e., shutdown and de-allocated), to release memory. An applet thus destroyed can no longer enact user notification functions when events occur that are relevant to the destroyed applet.
A method and apparatus for performing user notification is described. In a desktop environment in which multiple applications or applets may be simultaneously resident in main memory, it may be necessary to release or unload one or more applications or applets from main memory to provide memory space for a newly selected application or applet. Applications or applets thus unloaded are incapable of providing feedback or user notification of state changes associated with the respective application or applet. An embodiment of the invention provides a user notification class for notifying users of application or applet state changes. For each application or applet that needs to provide user notification, a desktop manager loads an instance of a notification class as a thread which will operate even when the associated application or applet is not resident in main memory. The user notification class instance performs all notification functions on behalf of the application or applet. An event mechanism is provided for an application or applet to communicate with its user notification thread. Also, an application or applet may access the methods of its associated user notification class.
In one embodiment of the invention, the desktop manager is an application running in a Java(trademark) runtime environment, with other applications embodied as applets which may be selected via button icons in a selection bar. Upon startup, the desktop manager accesses a configuration file specifying the button icons to be displayed in the selection bar. The configuration file also contains information associated with each button icon, including the URL of an HTML document containing the desired applet to be invoked upon selection of the button icon, several default images for the button icon, and the location of the code for the notification class to associate with the button icon and its applet. The desktop manager displays each button icon in the selection bar, and loads the respective notification classes based on the information in the configuration file.
An instance of a user notification class performs user notification functions on behalf of the applet, for example, by changing the image or images associated with the button icon, by displaying a message in a dialog box, by playing an audio clip, or by performing some combination of notification mechanisms. An applet communicates with its associated notification class instance by obtaining a reference to the notification class instance from the desktop manager, and either placing an event onto the event queue of the notification class instance or accessing the methods of the notification class instance directly. In this way, an applet can be restricted to communicate only with its associated notification class. For applet events, the notification class instance interprets the type of event from the event ID and handles the event as appropriate.